Proposed by Carla Griggio (profile, biography)
Who am I
I'm Carla, I'm from Argentina and right now I'm studying Human Computer Interaction and Design at Université Paris Sud in France. You can check my detailed bio here: http://gsoc2013.esug.org/carla-florencia/biography
Why do I want to do this project
I've been attracted to this project since its 2011 version. I even built some widgets for an old version of Mars, but I couldn't pay much attention to the project back then, which had a less stable architecture than today.
I think Pharo should be more mainstream and there are two issues against it that could be solved with Mars:
- Pharo's user interface feels strange to newcomers, and many people usually don't like changing too much from what they are used to. A way to build native UIs with Pharo would help to address this problem in two ways:
- A new IDE with a native UI could be built, so new developers (and also current ones!) have a more familiar UI to work on, also more responsive and integrated with the user's OS.
- The desktop products developed with Pharo could have a similar look & feel to other applications running on each OS, which will help the final user understand how to interact with the application based on the patterns and affordances he's already used to have in his other applications.
- There are a lot and great ready-to-use widgets and components for native UI out there that the Pharo developer can't take advantage from. Mars could be a first step to have better interoperability between Pharo and its outside world regarding UI frameworks (the same way developers write Seaside plugins that translate into JQuery-UI plugins, developers could integrate, for example, Cocoa widgets into Mars to let everybody reuse them).
Mars has already had working prototypes, so we know it's feasible and I believe that some months of full time work on it can finally end in a release that will let more people start trying it and being interested in joining the dev team.
Besides that, my main field is HCI and UI development so designing a framework to build UIs it's very interesting to me. I also have a lot of fun with metaprogramming, so I look forward to build the IDE demo application to interact with Pharo's meta model.
How will I do the project
First, I have a lot of code to analyze and understand to see where are the current problems of the design of the framework, what is missing and what is already done. Stating what improvements will have to be done for Mars 1.0 is the first thing to do, as it will also guide me into understanding its current design.
I will not follow a TDD approach strictly speaking, but related to the same idea I want to agree on a basic native Pharo IDE application design with the mentors that will lead the development of the project through all the program. All the widgets and interactions supported by Mars will be inspired by that application, that serves also as the first demo of Mars (and of course, as a starting point for a native IDE!).
This demo would consist of a basic IDE that let the user:
- Browse classes and select one
- See the variables and methods of a class
- Browse, add, edit and delete the variables and methods of a class
- Write code in a workspace, execute it and see the result
Despite I haven't yet agreed on a concrete interface design for this demo with the mentors, I can already guess it will cover at least the following widgets or components:
-
Window
-
Panel
-
Frame
-
Text input
-
Text area
-
Label
-
Button
-
Image button
-
Image view
-
Linear menu
-
Tabular menu
-
Checkbox
-
Radio button
-
Scroll / Slider
-
List
-
Combo box
-
Tooltip / Pop over
Mars should provide a uniformed way of describing these widgets and then handling the specific platform rendering and callbacks by itself. The concrete strategy for implementing this depends on the result of the analysis of the current version of Mars and the improvements on the framework design that have to be done.
On the other hand, the user interface designer will most likely want to program interactions too, from basic commands like a double click to more complex interaction techniques like drag & drop. As event handling has to be decoupled from the platform specific UI framework too, a good approach will be to find an abstraction for describing interactions and event handlers.
Recently I used the framework "Swing States" at my university, which lets the developer describe interactions as state machines. I think it's a very cool and simple way of programming interactions in a high level manner and a Smalltalk implementation of this idea could be very useful for Mars (and it would be possible to take advantage of that in other UI frameworks too, even Morphic)**. This counts also as a step for making native UI programming not only possible but also easy and maintainable :)
And a third thing to take into account is the Application itself that will manage the windows, main menu and application level events (like closing the whole application, not just a window). This also changes from platform to platform and the Mars user should not have to care about it.
Apart from these subjects, I would very much like to add bindings a.k.a. "active values".
What methodologies will I use
I don't see myself applying any particular methodology for this project, other than establishing some milestones and give quick feedback to the community on the progress. In general, I will:
-
Keep a blog publishing the problems I find in the process, how did I understand what was wrong and how did I solve it.
-
Record screencasts as the results progress.
-
Share updates and problems often with the community to get quick feedback, at least weekly.
-
Do as many automated tests as I can (and soon) to support future refactoring.
I can think of two ways of approaching the design of the Mars framework:
-
Start implementing everything for only one platform, get all the widgets done and the demo working, and then move to the next one
-
Try to get very few widgets working on all platforms, and then adding more widgets until getting the demo working on all platforms.
My intention for now is to follow the second approach, as it will help better to get a flexible design from the beginning.
The following is a tentative and "overviewish" timeline with milestones, as it will surely change after analyzing the improvements that have to be done with the mentors and during the whole program because of the feedback from the community I will get from time to time:
-
June 17: Ready to go! Community Bonding Period ends. I will catch up with the current version of Mars and learn the tools and languages I will have to use (mainly NativeBoost, GTK and Windows Forms).
-
August 2: First ~10 widgets working on the 3 platforms, with basic event handling of the widgets (click, double click, mouse over, mouse out, focus, blur, …). Midterm Evaluations!
-
September 16: All the widgets working on the 3 platforms. Platform specific widget instances. Bindings.
-
September 27: GSoC deadline. Wrap up of the project and its documentation.
Where I see the risks
-
Each operating system has its own user interface look & feel and design guidelines, and trying to find widgets that can be written once with Mars and rendered differently according to the operating system where the app is running could lead to breaking those design guidelines. I will pay attention to identify these cases, and also provide the option to the programmer to specify how a widget should look like in each separate platform. Other similar projects have already dealt with this problem, like Chromium, so they could be studied to learn from their experience.
-
Automatic testing will be challenging, as the best comprehensive way of testing this project should include testing different interactions done on the generated native UI, so if this is not solved from the beginning, the project might lack vital automatic tests once it starts growing, and refactors will be harder to do.
How the results will look like
The results could be seen as different "deliverables":
-
The working code of Mars 1.0
-
A blog and screencasts documenting the progress little by little
-
Clear documentation and tutorials
-
A cross-platform demo application: the native Pharo IDE, with the basic features described above and separate documentation that will help others to collaborate to this new project
-
An "interaction state machine" framework that could be integrated with other UI frameworks for programming interactions.
Notes:
** The graphic representation of the interaction state machine would not enter in the scope of the project, unless there's extra time for it. The focus is just taking the idea of describing interactions as state machines, using a State pattern.
|